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ABSTRACT 



In the proposed Local Number Portability (LNP) telecom- 
munications network, the traditional link between the first 
six digits of a ten-digit dialed number and the geographic 
link of a switch is broken. Some pre-LNP telephone 
services, however, have been implemented based on this 
geographic link. For the services to continue to work in an 
LNP environment, network databases must be simulta- 
neously updated with information reflecting the fact that 
subscribers have switched from one local service provider to 
another. If these databases are not simultaneously updated, 
the possibility for looping messages between network ele- 
ments arises. The present invention provides a method and 
system for controlling looping messages between network 
elements wherein a unique code for each incoming message 
is generated and stored along with the time the message was 
received. The codes for subsequently received messages are 
checked against the table entries to determine if the message 
has been previously received and, if so, how much time has 
passed since the message was first received. If this time is 
less than a threshold, the message is assumed to be looping. 

22 Claims, 5 Drawing Sheets 
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SYSTEM AND METHOD FOR again dials *69, and an SSP 22 determines that the call 

CONTROLLING MESSAGE LOOPING requires assistance from ISCP 26. The SSP 22 launches a 

BETWEEN NETWORK ELEMENTS message to the STP 24, which directs the message to the 

appropriate ISCP 26. The ISCP 26 determines the SPC of the 

BACKGROUND OF THE INVENTION 5 appropriate ISCP 27 or STP 28 in Network B and routes the 

The present invention relates generally to local number messag^riiiitfy. The database (not shown) associated 

portabiUty (LNP) in a telecommunications network, and with ISCP 27 in Network B however has not been updated 

more particularly to controlling looping of messages in an to reflect the fact that the subscnber has ported from 

LNP enabled network. Network A to Network B. Thus, when ISCP 27 of Network 

„ , , , , ■ • j . u • ■ 10 B checks its database, it determines that the subscnber is still 

Currently, local phone service is provided by a single iscp 2? ^ ^ 6 t0 STp 

^A 3 ^ 35 3 8 r I Opiating Company ^ ^ s ^ 

RBOC). These companies basically enjoy a monopoly over m back ^ betweeD ^ nelworks 

local phone service within their regions Thus efforts are ^ have ^ been d 

being made to introduce competition into the local phone J . , „_ 

market to eliminate the monopolies and relieve the need to 15 Th^mg-mc^gc^^y^^^aetwo^^tA 

regulate the industry. Under the current system, however, if N^work^pd^fe^dat^ 

customers want to change from one service provider to cOTrej^route^^ 

another, they must also change their phone numbers. This is 'looping problem is serious, because of «bemely high 

a serious deterrent to switching service providers and, thus, volume or multiple looping messages, the ISCP^overload^ 

a hindrance to free and open competition. 20 mechamsm.wiUrautomatically^det^cUhe ov erload co ndition^ 

To alleviate the problem, the FCC has issued an order for and-Jaketoej^ary.stepsUo-dro 
LNP which, in addition to providing other features, will "During the interim, however, the looping message con- 
allow a customer to switch between local service providers sumes network capacity. Assuming it takes approximately 
while keeping the same phone number. „ 200 ms for a message to reach Network B's ISCP from 
. . , xm . i u ^ 1 .i. « . • 25 Network A's ISCP, the round-trip will take 400 ms. This 

(71 ™? ^vT^fn h rK u h H^K , results in the loss of about 3 q/s of capacity for each looping 

» digits (NPA-NXX) of a 10 digit phone number idenufy a g ^ ^ ^ 

particular switch m a particular geographic region. Switches ° K " . . . _T , . „„„._:,„ 

v I, i u l j .u xtt>a kivv f only two networks are involved. The dram on capacity 

can route calls between switches based on the NPA-NXX of ' . ... . ,. JT ' 

, .. , , . , , xm • . u .u- would be even more significant if intermediate networks are 

the dialed number. In an LNP environment, however, this ,„ . . . . °. 

, . , ^ ii_ xm a in™ i .i i • i| JU mcluded in the calculation, 

■relationship between the NPA-NXX and the physical loca- . 

tion of a switch is broken, such that there is no fixed Currently, no mechanism exists that would allow the ISCP 

relationship between a dialed number and its geographic to detect looping messages. There is, therefore, a need for a 

location. Many existing telephone services such as calling system and method to detect and eliminate looping messages 

card services, automatic callback, and services relating to 35 before an overload condition is detected by the ISCP. 

voice mail and voice messaging, however, have been imple- SUMMARY OF THE INVENTION 
mented based on this geographic relationship. If the change 

to an LNP environment is to succeed, existing services (i.e., To achieve these and other advantages and in accordance 

pre-LNP services) must continue to work in the new LNP with the purposes of the invention, as embodied and broadly 

environment. 40 described, a method consistent with the present invention 

Implementation of LNP is creating new network prob- 4 jr include s the steps of receiving a message, generating a code 

lems. The caU flow diagram of FIG. Lhelps Ulustrate one'af 4 V t0 uniquely identify the message, determining if the code 

these problemsxTake.forexample,^ matcheS 006 ° f P reviousl y stored codes - md ' d ^ code 

wrSre^^mpetmg^^etworksEA^-B-eHSt-in^ matches one of previously stored codes, comparing the time 

smde^eo^aphic region. Sup pose a caller 10 i n Network^ 45 ,he messa 8 e was received to a tua l « sso «* ted with the 
dials^69BrTn£th^last-person-that-called-caUer-10-is-T» previously stored code to determme if the difference is less 

subjcnber^o-has;s^ man a predetermined interval. 

fe~Netw6?OTpra^er.-I^^^ A system consistent with this invention includes a node 

nebusTyTSp~dated:with the jnfor mation.that the subscribe^has for receiving a message, a code generator to generate a code 

portedJ^ aOgggsssffig^^ uniquely identifying the message, a device for determining 

Se^c&Swutcfi^P^ \ if the code matches one of previously stored codes, and a 
mvoking ^e^69-caU-back-s erviceLwhich-requ ires-assiajnce 



fromjuiJrite^ratedJkryi^^ 

launches a message to_aJ>iRnaU^gTransfer-Pomt-(STP)Tl4. J 



comparator for comparing the time the message was 
received to a time associated with the previously stored code 
to determine if the difference is less than a predetermined 



w hich^irects'Jhe Tnessa^ interval. 
l8-dctcrmines-the_Signalin g~Point Cod _e_(SP.C).(i.e.,-the i\. It is to be understood that both the foregoing general 
Address of a networlTele^e^SMeiapp^lpriate-IS.CP^sor description and the following detailed description are exem- 
STP^lS-iFNetwoTk^B^aiid-routeSrtherme^a ge-accordin gly. JTf^plary and explanatory and are intended to provide further 
ISC^17;^f^erwo^B r cbecT^its^ <*\ explanation of the invention as claimed. 

<:routes3the-reQueste»J^f6rmation"to - Network"B's"SSP~19, 
whichcoapJte^t^aU^ ? BRIEF DESCRIPTION OF THE DRAWINGS 

If,_as-assumed— aboven^ach-network-is:;updatedr7 The accompanying drawings, which are incorporated in 

^simulta eouily,-no-problems;arise. Under the current LNP and constitute a part of the specification, illustrate presently 

"requkenientsrhowever, the network databases may not be preferred implementations of the invention and, together 

updated simultaneously. Suppose in the previous example 65 with the general description given above and the detailed 

that Network A updates its database before Network B. The description of the preferred implementations given below, 

resulting call processing is shown in FIG. 2. A caller 20 serve to explain the principles of the invention. 
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FIG. 1 is a diagram showing ideal call processing in an 
LNP environment; 

FIG. 2 is a diagram showing a looping message in a LNP 
environment; 

FIG. 3 is a flow chart of a method for detecting looping 
in an LNP environment in accordance with an embodiment 
of the present invention; 

FIG. 4 is a flow chart showing ISCP processing according 
to one value of a looping indicator stored in the ISCP 
database in accordance with an embodiment of the present 
invention; 

FIG. 5 is a flow chart showing ISCP processing according 
to another value of a looping indicator stored in the ISCP 
database in accordance with an embodiment of the present 
invention; and 

FIG. 6 is a diagram of a system for detecting looping in 
accordance with an embodiment of the present invention. 

DETAILED DESCRIPTION 

Reference will now be made in detail to the construction 
and operation of preferred implementations of the present 
invention which "are illustrated in the accompanying draw- 
ings. 

The following description of the preferred implementa- 
tions of the present invention is only exemplary of the 
invention. The present invention is not limited to these 
implementations, but may be realized by other implemen- 
tations. 

Consistent with the present invention, the ISMS database 
(not shown) of each ISCP in the network is enhanced with 
two additional parameters: 1) a monitor interval, preferably 
ranging from 1 to 30 seconds; and 2) a looping indicator, 
preferably taking on values 0, 1, or 2. Briefly, time differ- 
ences between received messages are compared against the 
monitor interval to determine if they are looping. The 
looping indicator determines whether the ISCP looping 
detection algorithm is activated and, if so, what action the 
ISCP takes upon detecting a looping message. Both param- 
eters are configurable from a network maintenance and 
operations console (MOQ (not shown). 

ISCP message processing consistent with the present 
invention is shown in FIG. 3, and the overall system is 
shown in FIG. 6. The ISCP receives a message from an STP 
over SS7 links 60 (step 305). The ISCP checks the looping 
indicator in its database (step 315). If the looping indicator 
is set to 0, looping detection is turned off. Therefore, the 
ISCP processes the message normally (step 320). 

If the looping indicator is set to 1 or 2, the ISCP parses the 
received message to determine the Originating Point Code 
(OPC) (i.e., the address of the network element originating 
the message), 10 digit dialed number, and transaction capa- 
bility application part (TCAP) transaction ID (step 325). The 
ISCP concatenates these values and a checksum computed 
for the TCAP portion of the received message to form a 
unique code 64 for the received message (step 330). The 
ISCP then compares the code with codes that have been 
previously stored in table 62 (step 335). 

If a match is found, the ISCP compares the time the 
message was received with a time stamp 66 associated with 
the stored code (step 340). The stored time stamp 66 
represents the time the stored code was received. If the 
difference between the stored time and the time the current 
message was received is less than the monitor interval, the 
ISCP assumes the message is looping. In this case, a network 
has launched a message and received a message having the 



70,452 

4 

same unique code in a short time, indicating that it is highly 
likely the same message. 

When the ISCP detects a looping message, it again checks 
the looping indicator to determine the next step (step 345). 

5 As shown in FIG. 4, if the looping indicator is set to 1, the 
ISCP logs an alarm, preferably noting the following infor- 
mation from the looping message: the OPC, 10 digit dialed 
number, Global Title Address (GTA), incoming Translation 
Type (TT), and the first 40 bytes of the TCAP message in 

io hex format (step 405). The alarm is generated for up to 10 
looping messages per 5 minute interval. 

As shown in FIG. 5, if the looping indicator is set to 2, the 
ISCP logs an alarm, preferably noting the following infor- 
mation from the looping message: the OPC, 10 digit dialed 

15 number, the GTA, incoming TT, total number of messages 
dropped, and the first 40 bytes of the TCAP message in hex 
format (step 505). Once this information is logged at the 
ISCP, the message is discarded (step 510). The alarm is 
generated for up to 10 looping messages per 5 minute 

20 interval. 

Returning to the processing at step 340 in FIG. 3, if the 
difference between the stored time and the time the message 
was received is greater than or equal to the monitor interval, 
the ISCP assumes the message is not a looping message but 

25 is, instead, a new message. In this case, table 62 is updated 
with the new message information. Since there is already an 
entry in table 62 matching the code of the received message, 
only the time stamp associated with that matching entry 
need be updated. Thus, the ISCP replaces time stamp 66 

30 associated with the previously stored code with the time the 
current message was received (step 350). Normal message 
processing then continues (step 320). 

If in step 335, no match is found between the code and the 

35 previously stored codes, this indicates that the ISCP has not 
previously processed this message. Thus, the code and the 
time the message was received are added to table 62 (step 
355). Message processing then proceeds normally (step 
320). 

40 Based on current tests, a message will be processed, on 
average, 4 to 6 times before being detected. When the STP 
is load sharing messages between mated pairs by directing 
one set of NPA-NXX's to one ISCP, and the rest of the 
NPA-NXX's to another ISCP, the looping message could be 

45 processed up to 12 times before being detected. These more 
extreme situations could be accounted for by increasing the 
monitor interval. 

Preferably, the table generated by the ISCP is twice the 
size necessary to accommodate the ISCP operating at full 

50 load. Thus, at full load, only half of the entries in the table 
will be valid. That is, only half the entries will have time 
stamps within the monitor interval from the current time. 
The other entries will represent older messages received 
more than the monitor interval before the current time. In 

55 step 335, when a code does not match a previously stored 
code, one of these older entries is overwritten with the new 
code and time stamp (step 355). 

While there has been illustrated and described what are at 
present considered to be preferred embodiments and meth- 

60 ods of the present invention, it will be understood by those 
skilled in the art that various changes and modifications may 
be made, and equivalents may be substituted for elements 
thereof without departing from the true scope of the inven- 
tion. 

65 In addition, many modifications may be made to adapt a 
particular element, technique or implementation to the 
teachings of the present invention without departing from 
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the central scope of the invention. Therefore, it is intended 
that this invention not be limited to the particular embodi- 
ments and methods disclosed herein, but that the invention 
include all embodiments falling within the scope of the 
appended claims and their equivalents. s 
We claim: 

1. A method for detecting message looping between 
network elements comprising the steps of: 

receiving a message; 

generating a code to uniquely identify the message; 10 
determining if the code matches one of previously stored 
codes; and 

if the code matches one of previously stored codes, 
comparing the time the message was received to a time 55 
associated with the previously stored code to determine 
if the difference is less than a predetermined interval. 

2. The method of claim 1 further including the step of: 
if the difference between the stored time and the time the 

message was received is less than the predetermined 20 
interval, generating an alarm. 

3. The method of claim 1 further including the step of: 

checking a looping indicator. 

4. The method of claim 3 further including the step of: 
performing normal message processing without looping 25 

detection if the looping indicator has a first predeter- 
mined value. 

5. The method of claim 3 further including the step of: 

if the difference between the stored time and the time the 3Q 
message was received is less than the predetermined 
interval, generating an alarm. 

6. The method of claim 5 wherein the alarm generating 
step includes the steps of: 

logging a major alarm at an 1SCP if the looping indicator 35 
has a second predetermined value; and 

providing the ISCP with an Originating Point Code 
(OPC), ten digit dialed number, Global Title Address 
(GTA), incoming Translation Type (TT), and the first 
40 bytes of a Transaction Capability Application Part 40 
(TCAP) message if the looping indicator has the second 
predetermined value. 

7. The method of claim 5 wherein the alarm generating 
step includes the steps of: 

if the looping indicator has a third predetermined value, 45 
logging a minor alarm at an ISCP; and 

providing the ISCP with at least one of an OPC, ten digit 
dialed number, GTA, incoming TT, total number of 
messages dropped, and the first 40 bytes of a TCAP 
message. 50 

8. The method of claim 7 further including the step of: 
discarding the message. 

9. The method of claim 1 further including the step of: 

if the difference between the time said message was 55 
received and the time associated with the previously 
stored code is greater than or equal to the predeter- 
mined interval, replacing the time associated with the 
previously stored matched code with the time said 
message was received. 60 

10. The method of claim 1 further including the step of: 
if the code does not match one of previously stored codes, 

storing the code and the time the message was received. 

11. The method of claim 10 wherein the storing step 
includes the step of: 65 

storing the code and the time the message was received in 
a table. 
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12. The method of claim 10 wherein the storing step 
includes the step of: 

overwriting a previously stored entry whose stored time is 
more than the predetermined interval before the current 
time. 

13. The method of claim 1 wherein the step of generating 
a code includes the steps of: 

extracting an originating point code (OPC) from the 
message; 

extracting a ten digit dialed number from the message; 
extracting a TCAP transaction identification from the 
message; 

computing a checksum for the TCAP portion of the 

received message; and 
concatenating the OPC, ten digit dialed number, TCAP 

transaction identification, and checksum to form the 

code. 

14. The method of claim 1 wherein the comparing step 
includes the step of: 

comparing the time the message was received to a time 
associated with the previously stored code to determine 
if the difference is less than a predetermined interval 
ranging from one to thirty seconds. 

15. A system for detecting message looping between 
network elements comprising: 

a node for receiving a message; 

a code generator to generate a code uniquely identifying 
the message; 

means for determining if the code matches one of previ- 
ously stored codes; and 

means for comparing the time the message was received 
to a time associated with the previously stored code to 
determine if the difference is less than a predetermined 
interval. 

16. The system of claim 15 further including: 

means for generating an alarm if the difference between 
the stored time and the time the message was received 
is less than the predetermined interval. 

17. The system of claim 15 further including: 

means for replacing the time associated with the previ- 
ously stored matched code with the time said message 
was received if the difference between the time said 
message was received and the time associated with the 
previously stored matched code is greater than or equal 
to the predetermined interval. 

18. The system of claim 15 further including: 

means for storing the code and the time the message was 
received if the code does not match one of previously 
stored codes. 

19. The system of claim 18 wherein the storing means 
includes: 

a table for storing the code and the time the message was 
received. 

20. The system of claim 18 wherein the storing means 
includes: 

means for overwriting a previously stored entry whose 
stored time is more than the predetermined interval 
before the current time. 

21. The system of claim 18 wherein the code generator 
includes: 

means for extracting an originating point code (OPC) 

from the message; 
means for extracting a ten digit dialed number from the 

message; 
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means for extracting a TCAP transaction identification 

from the message; and 
means for concatenating the OPC, ten digit dialed 

number, and TCAP transaction identification to form 

the code. 

22. The system of claim 15 wherein the comparing means 
includes: 



8 



means for comparing the time the message was received 
to a time associated with the previously stored code to 
determine if the difference is less than a predetermined 
interval ranging from one to thirty seconds. 
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